Neste curso, nosso foco será 100% no **modelo relacional**.
[ *Ilustração: Duas tabelas simples (Clientes e Pedidos) se conectando por uma linha (id_cliente)* ]
[ *Ilustração: Ícones de pessoas conversando, documentos e listas de tarefas.* ]
---
## Fase 2: Exemplo de DER Completo
Para a nossa loja, o diagrama conceitual completo seria mais detalhado, especialmente para lidar com os itens de um pedido.
- **Entidades**: `CLIENTE`, `PEDIDO`, `PRODUTO`.
- **Relacionamento N:M**: Um `PEDIDO` pode ter vários `PRODUTOS`, e um `PRODUTO` pode estar em vários `PEDIDOS`.
- **Solução**: Criamos uma entidade associativa chamada `ITEM_PEDIDO`.
<br>
[ *Ilustração: Diagrama ER com as 3 entidades principais. CLIENTE se liga a PEDIDO. PEDIDO e PRODUTO se ligam à entidade associativa ITEM_PEDIDO no centro.* ]
- **CLIENTE** (`id_cliente`, nome, email)
- **PEDIDO** (`id_pedido`, data, status)
- **PRODUTO** (`id_produto`, nome, preco)
- **ITEM_PEDIDO** (`quantidade`, `preco_unitario`)
**Leitura do Diagrama:**
- Um `CLIENTE` faz (1,N) `PEDIDOS`.
- Um `PEDIDO` é composto por (1,N) `ITENS_PEDIDO`.
- Um `PRODUTO` pode estar em (0,N) `ITENS_PEDIDO`.
- **Independência**: Ainda não depende de um SGBD específico (MySQL, PostgreSQL, etc.).
- **Dependência**: Totalmente ligado ao SGBD escolhido.
[ *Ilustração: Ícones de engrenagem, um velocímetro e logos de SGBDs (MariaDB, PostgreSQL).* ]
---
# Garantias ACID: A Base da Confiança
Por que podemos confiar em uma transação bancária? Por causa do **ACID**. Todo SGBD relacional sério segue essas 4 propriedades para garantir a integridade das transações.
- **A**tomicidade
- **C**onsistência
- **I**solamento
- **D**urabilidade
Vamos ver cada uma.
---
### Atomicidade (A)
> Uma transação ou acontece **por completo**, ou **não acontece nada**.
É a regra do "tudo ou nada".
- **Exemplo**: Em uma transferência bancária, a operação envolve duas etapas: debitar da conta A e creditar na conta B.
- Se o sistema falhar após o débito, mas antes do crédito, a atomicidade garante que a operação inteira seja desfeita (`rollback`).
- **Nunca** existirá uma "meia transferência".
---
### Consistência (C)
> A transação só é concluída se todas as **regras do banco** forem satisfeitas.
O banco de dados sempre estará em um estado válido.
- **Exemplo**: Uma regra de negócio pode ser que o saldo de uma conta não pode ficar negativo.
- Se uma transferência for maior que o saldo disponível, a transação é bloqueada e desfeita, mantendo a consistência dos dados.
- Outras regras incluem tipos de dados (não inserir texto em campo de data) e chaves estrangeiras.
---
### Isolamento (I)
> Transações concorrentes **não interferem** umas nas outras.
É como se cada transação acontecesse em sua própria "bolha", em sequência, mesmo que estejam rodando ao mesmo tempo.
- **Exemplo**: Se duas pessoas tentam comprar o último ingresso para um show ao mesmo tempo, o isolamento garante que apenas uma delas consiga.
- O SGBD gerencia "filas" e "travas" internas para evitar que uma transação leia dados "sujos" (ainda não confirmados) de outra.
---
### Durabilidade (D)
> Uma vez que a transação é confirmada (`commit`), ela é **permanente**.
Os dados não serão perdidos, mesmo que o sistema falhe (ex: queda de energia) logo em seguida.
- **Como?** O SGBD escreve as alterações em um **log de transações** em disco antes de confirmar a operação.
- Se o sistema cair, ele usa esse log para reconstruir o estado do banco de dados e garantir que nenhuma transação confirmada seja perdida.
Tudo que aprendermos para um, vale para o outro.
- Tirar um print da tela do phpMyAdmin mostrando o banco de dados `aluno` criado e o usuário logado.